This invention generally relates to the system administration of a computer system, and more particularly, to a task manager system and method for creating and performing system management tasks on one or more computer systems.
The operating system of most computers provides an administration tool or a system administration manager for invoking and performing system management tasks. The hardware of a computer system, the various facilities included within the operating system, such as the file system facility, the print spooling facility, and the networking facility, as well as the operating system itself must all be managed. This predicament means that computer systems require some involvement by a human user or a manager of the computer system for such operations as specifying certain configuration parameters, monitoring ongoing activity, or troubleshooting some problem that has arisen. These management or administration tasks can be performed manually in many operating systems via direct manipulation of configuration files or direct invocation of specific administration utility programs. But in most modern operating systems, an easy to use, interactive software program is typically provided that hides the details of the file formats and the utility program syntax, while providing a higher level presentation for the user. This program, hereinafter referred to as the system administration manager (SAM), performs the query tasks on behalf of the user and then displays the discovered configuration and status information to the user in an easily manipulated format. The SAM also performs configuration or status change tasks on behalf of the user, and thus, provides an easy mechanism or interface for specifying the details of the task to be performed.
The query tasks retrieve information about the current configuration and state of the system or facility being managed. Configuration change tasks actually make changes to the configuration or state of the system or facility. These tasks are implemented as either separate utility programs (referred to in the UNIX industry as xe2x80x9ccommandsxe2x80x9d) that are invoked by a command task manager or as a collection of functions contained in a shared library that are called by a function task manager. In addition, if the system or facility being managed is shared across multiple computer systems, some of these tasks must be performed on one or more of these computer systems simultaneously. This kind of distributed task would be performed by a remote task execution manager which communicates the task to be performed, with its associated parameters, to either a command task manager or a function task manager running on each of the other computer systems as appropriate.
In prior art implementations of the command task manager and function task manager on a single computer system, each task manager has its own application programming interface (API), task description language, and data structures. In addition, the support for such common features as error handling or event logging vary from manager to manager. These inconsistencies have led to numerous problems for developers of system management applications, four classes of which are discussed hereinafter.
A first and most obvious problem is programmer confusion. The different APIs and features have made the various task managers hard to learn, and therefore, have increased the training costs of software developers. This confusion is also the root cause of many programming errors.
A second class of problems is related to redundant implementations of similar functionality. This amounts to negligent use of the resources available to the SAM by requiring two sets of code to perform the same function implemented by separate facilities. Not only do these redundant implementations increase the initial cost of development, they also result in duplication in ongoing maintenance of the task managers, since similar changes or improvements have to be made in multiple places and in different ways.
A third class of problems is inconsistencies in the user interface from one task to another. The variation in task type invariably leads to variations in presentation to the user. This is undesirable since user interface inconsistencies are a leading cause of error and confusion for users.
And finally, the inconsistency between the command task manager and the function task manager have made it difficult to implement a remote task execution manager. Since the remote task execution manager must be able to communicate either with a command task manager or a function task manager on the remote computer system, depending upon the type of task being performed, any differences in the APIs of the two managers requires extra work in implementing the interface.
In the future, new technologies and protocols for both network and system management will lead to new ways to implement management tasks. Emerging standards will require new task execution managers that are uniquely configured to manage tasks implemented using those standards. Therefore, it is important to provide an extensible architecture for system management task execution to avoid any more proliferation of inconsistent APIs, description languages, and data structures.
Thus, a heretofore unaddressed need exists in the industry for a system and method that provides for all task execution management functions using a single interface and that is more extensible than existing implementations.
The present invention overcomes the inadequacies and deficiencies of the prior art as disclosed hereinbefore and as well known in the industry. The present invention provides for a task manager that can be employed as a part of a system administration manager (SAM) on a computer system. The task manager provides a simple and consistent interface for creating and performing management tasks, combining the features of the function task management, command task management, and remote or distributed task execution management. The task manager provides a single API for all task execution, a single task description language to specify the implementation of tasks, common shared functionality for such things as error handling, event logging, task description registration, and a command line interface. In the preferred embodiment, the present invention operates in conjunction with a task registration manager and a plurality of sub-managers including a command task manager, a function task manager, and a remote task execution manager.
A management task is defined for purposes of the present invention as an organized collection of one or more separate operations performed on a system or facility for purposes of retrieving configuration or status information from, or making configuration or status changes to, the system or facility. Each management task is identified by a string keyword identifier, defined in a task description file, and implemented as one or more callable functions in a shared library, as a command or script, or as an operation on a shared distributed resource. The target of a management task request can be the local computer system or host on which the task manager is currently installed and running and/or one or more remote computer systems.
Since all of the aforementioned features of the task manager are brought together under a single manager interface and the tasks are described in a common language, the architecture of task management is simpler and more efficient than that in the prior art because it can leverage the jobs performed by the various sub-managers.
In accordance with a feature of the present invention, remote tasks are described in platform independent terms, greatly facilitating the distributed execution of tasks in a heterogeneous environment. The tasks are uniquely identified not by how they are performed, but by a string identifier or name. Therefore, the implementation of a task on one computer system can be different than that on another and yet a single remote task execution manager can request the same task be performed on both regardless of the differences in implementation. Also, by implementing a single facility that brings together all of the task management features into one application program interface (API), the developer of the system management application that invokes these tasks need not know the implementation of the task being executed in order to perform the task. In addition, the implementation of any specific task can be changed from one type to another without requiring changes in the application program that invokes the task as long as the task interface (i.e., the number, type, and meaning of the parameters passed to the task) is unchanged.
In architecture, the task manager is configured in a computer memory as a set of instructions and shared data structures that can be shared among one or more system management application software programs and includes a single API that can be used to invoke one or more sub-managers. For purposes of illustrating the present invention, the sub-managers include a function task manager, a command task manager, and a remote task execution manager. A task registration manager and an abstract data access facility interact with the task manager in order to support its operation. When implementing the present invention as a program on a generic computer, the computer is reconfigured into a specific computer for operating in the manner described herein.
The present invention can be thought of as a portion of a software program comprising executable instructions (i.e., computer readable) encoded in a computer memory so as to cause the computer to function in the following manner. Initially, the task manager receives a request to perform a particular management task by a calling program. The task manager first obtains the task description for that task from the task registration manager. At essentially the same time, the task registration manager looks up and loads into memory any shared libraries necessary for the execution of the requested task. The task manager then creates and initializes a dynamic task state data structure into which all the information gathered by the task manager about the operation of the task, i.e., the task detail and its execution modes, is inserted. Next, the task manager determines whether the target of the task is the local host or a domain of hosts based upon either the task type or the parameters of the request. If the target is a domain, the task is sent to the remote task execution manager for execution. If the target is the local host, as is most often the case, the task manager determines whether the task is a command or function task and then sends the task to the appropriate sub-manager for execution. Upon completion of the execution of the task by the sub-manager, the dynamic state data structure is disposed of and the error status of the task and any resultant data is returned to the calling program.
Command tasks targeted at the local host are passed off to the command task manager where a command invocation string is created from a combination of the task description and data parameters passed off with the task. A separate process is then forked for executing the created command string via a POSIX shell. A post processor examines the post processing directives in the task description and processes the output objects (i.e., the output and error data and the command exit code) of the command per those directives. Lastly, the results are returned to the task manager.
Function tasks targeted at the local host are passed off to the function task manager where one or more (e.g., C language) functions are called. Presumably, these functions are configured as part of a shared library that is part of the system management application. However, these functions may be configured as part of the main software program (such as in those defined in a common set of generic utility tasks). This shared library will already be loaded as hereinbefore described. The function task manager, in the preferred embodiment, supports three function types: an init function, a perform function, and a cleanup function. The perform function must be specified in the task description and is the function that performs the actual task operations. The init and cleanup functions are optional and serve to initialize and then cleanup or dispose of data structures used during the performance of the task respectively. If an init function is specified, it is called first. The perform function specified in the task description is then called and the return code of that function is optionally processed by an exit processor. Finally, if a cleanup function is specified, it is called.
Alternatively, command or function tasks targeted at a domain of host or domain tasks are passed of f to the remote task execution manager. Though the remote task execution manager is not the subject of the present invention, for purposes of disclosing and teaching the present invention, the remote task execution manager is briefly described herein. The remote task execution manager can be used either to execute a function or command task on some number of remote computer systems or to execute a domain task. It is assumed for purposes of the following discussions that the remote task execution manager (or domain task manager) is limited regarding the set of computer systems that can be the target of a remotely executed task. It is assumed for purposes of disclosing the present invention that the only domain supported are members of an NFS diskless cluster. The NFS diskless cluster is a set of computer systems that share a specific set of resources including a root file system server which uses the industry standard network file system protocol.
When a function or command task is passed off to the remote task execution manager, it determines the list of computer systems on which to execute the task by retrieving a list of members in the NFS diskless cluster of which the local computer is a member. It then uses a remote communication protocol over a computer network connection to invoke an agent software program on each of the target computer systems. It passes the task name and a copy of the passed in data parameters to each of these agent programs. Each agent program is configured to use the present invention to execute the task on the computer system on which it is running. When the present invention has completed the task execution and has returned its results to the agent, the agent passes the task results back to the originating remote task execution manager and then it exits. When all of the agent programs running on the target computer systems have returned their individual results, the remote task execution manager merges those results and returns them to the task manager.
When a domain task is passed off to the remote task execution manager, information about this specific task, i.e., the passed in data parameters, are used to update a database that is used to manage shared resources across the NFS diskless cluster. This database stores the intent of the user of the SAM regarding which resources are to be shared and the attributes of the shared resources so that, at a later time when a new cluster client system is added to the cluster, the process of adding the new client to the cluster will include automatically configuring the new system to use these same shared resources. Domain task descriptions include specifications regarding how to update the shared resource database. Optionally, a remote task can also be specified. This task must be either a command or a function task. If a remote task is specified, after any database updates have been performed, the remote task is executed on all the clients of the cluster in the same manner as hereinbefore described for executing remote command or function tasks.
An advantage of the task manager system and method of the present invention is that they provide enhanced ability to support independent development of related system administration products. Particularly, there are fewer architectural components to document and manage. Further, the single management interface configuration is more consistent and more understandable than the prior art multi-interface configuration.
Another advantage of the task manager system and method of the present invention is that they provide access to all management task available on the host computer system. For example, tasks written for the core system administration product are accessible to other add on or optional system management applications that also use the task manager.
Another advantage of the task manager system and method of the present invention is that they perform common operations such as event logging, error handling, and shared library look up and loading.
Another advantage of the task manager system and method of the present invention is that they insulate the task consumer from underlying technology changes, e.g., new protocols and other new technologies, as SAMs evolve over time.
Other features and advantages of the present invention will become apparent to one with skill in the art upon examination of the following drawings and detailed description. It is intended that all such additional features and advantages be included herein within the scope of the present invention, as defined by the claims.